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[57] ABSTRACT 

A dynamic derivation mechanism is denned which enables 
limited permissions to be dynamically and flexibly derived 
for executables based upon their authenticated description. 
The dynamic derivation mechanism uses the authenticated 
description to determine the maximal permissions that indi- 
vidual principals can delegate to the content. A principal's 
maximal permissions for content define a superset of the 
rights that that principal will actually delegate to that con- 
tent, ^though^the maximal pennissions^e^deriyed from^ 
predefined'specificationsTthe specifications can be sensitive 
to runtime state on the downloaded s system or previous 
"delegations to enable" the "d ypam icTflTeT, nmtime) derivltirjn . 
Multiple principals can delegate a subset of their niaximal 
permissions for the executable content/JTie mechanism uses^ 
policy^for^mblmng the "delegated perMssiolis^ ffioJiSeT 
^^ejU^sjruS permissio hs^ 
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FLEXIBLE AND DYNAMIC DERIVATION OF 
PERMISSIONS 

BACKGROUND OF THE INVENTION 
L Field of the Invention 

The present invention is related to a mechanism that 
enables flexible and dynamic derivation of permissions for 
system processes using an authenticated description of the 
executable content run by the process and a site security 
policy that prescribes the principals that can delegate per- 
missions to content of that description and limits to the 
permissions that may be delegated. 



Glossary 



Object 


Data containing 




entity. 


Operation 


An action that uses 




an object. 


Principal 


A system subject 




that performs 




operations on 




objects (e.g., process) 


Permissions 


The set of objects 




and operations that 




(or Access Rights) 




are permitted upon 




those objects for a 




specific principal. 


Current Permissions 


The permissions of 




a principal at the 




current time. 


Maximal Permissions 


A principal's 




permissions that is 




always a superset 




of that principal's 




current permissions. 



2. Discussion of the Prior Art 

Downloaded executable content are messages that contain 
programs that are executed upon receipt. It is well-known 
that downloaded executable content must be executed with 
limited permissions to prevent content providers from gain- 
ing unauthorized access to the downloading principal's 
resources (e.g., private files). 

However, deriving a proper, limited set of permissions 
that control the execution of content can be difficult. There 
are two main problems: (1) content can be transient, so their 
permissions must often be derived anew and (2) no single 
principal has complete knowledge of what permissions are 
required and safe for content. Content execution systems 
enable the creation of custom content that may only be 
executed once per downloading principal, so the derivation 
of permissions must not depend upon complete prior knowl- 
edge of its behavior. Several principals have limited knowl- 
edge about the permissions that a content should be granted, 
but no one has the breadth of knowledge necessary to derive 
content permissions. For example, system administrators are 
often trusted to specify permissions of processes completely 
(e.g., mandatory access control). However, the control of 
content requires that system administrators know how a 
custom application needs to access user data. System admin- 
istrators cannot know the rights needed by custom content 
nor can they know the semantics of user files, so they are 
limited in the access control decisions they can make. Other 
principals, such as users and application developers, may 
know these answers, but they are not completely trusted to 
make access control decisions. 

Current systems depend upon predefined mappings 
between content and principals. Typically, this mapping is 
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based upon the identity of an authenticated signer for the 
downloaded content. In addition, codebases (i.e., the source 
locations from which content was downloaded) are also used 
to identify the rights of content. Derivation of protection 

5 domains is limited because only one input is available and 
this input may be orthogonal to the rights required. The use 
of the signing principal or codebase to derive rights requires 
that all content from this principal or codebase be executed 
with the same rights. Therefore, when new content is created 

10 (and its associated public key or codebase) its rights cannot 
be derived even if the manufacturer and application class are 
known. A separation between author identity, location, and 
content description is necessary to overcome this limitation. 
Current systems demonstrate that multiple principals can 

15 provide information to derive content permissions, but these 
systems lack a model of how these principals interact to 
make such decisions. Most systems rely primarily on one 
principal to make access control decisions, such as the 
content execution system developer (see S. Thomas, The 

20 Navigator Java Environment: Current Security Issues, at 
web site (URL), http://developer.netscape.com/library/ 
documentation/j avasecurity.html, which describes the 
Netscape 2.0 and 3.0 security model) or the user (see T. 
Jaeger et al., Implementation of a Discretionary Access 

25 Control Model for Scrip ted-based Systems, in Proceedings 
of the 8th IEEE Computer Security Foundations Workshop, 
pgs. 70-84, 1995). Most systems provide access control 
mechanisms, but make no commitment to how permissions 
are derived (see N. Borenstein, Email with a Mind of Its 

30 Own: The Safe-Tel Language for Enabled Mail, ULPAA '94 
Proceedings, pgs. 389—402, 1994 as an early example). A 
few systems use multiple means for deriving permissions. 
FlexxGuard enables users and/or system administrators to 
select permissions for content, but users have the ultimate 

35 decision -making power (see N. Islam et al., A Flexible 
Security System for Using Internet Content, in IEEE 
Soflw HSi£iL^ 2-59 ' Se P temDer > 1997). In Me,tseaW isftfi% 
(Sa^rjilitael^^I (see Netscape Communications Corp., 
Introduction to the Capabilities Classes, at URL html for the 

40 Netscape 4.0 security model), application developers 
request access rights within a limited domain specified by 
users and/or system administrators. However, users are not 
limited in the rights that they can delegate to content, and the 
content developer can obtain any rights within the maximal 

45 permissions by simply activating them. In a Tel flexible 
content interpreter (see T. Jaeger et al., Building Systems 
That Flexibly Control Downloaded Executable Content, in 
Proceedings of the Sixth USENIX Security Symposium, 
pgs. 131-148, 1996.), system administrators can define how 

50 application developers may limit other content's access 
rights, but users may not grant rights. 

RBAC models have also been used extensively to repre- 
sent access control policy management, but also presently 
lack the flexibility to express how multiple principals can 

55 affect common access control decisions. RBAC models 
permit principals to assume a role, which is another principal 
with its own permissions. RBAC models are often used by 
system administrators to specify mandatory access control 
(MAC) policies (see R. Sandhu et al, Role -based Access 

60 Control: A Multi-Dimensional View, Proceedings of the 10th 
Computer Security Applications Conference). A MAC sys- 
tem partitions the world into two groups: (1) system admin- 
istrators who specify access control policy and (2) users that 
are controlled by the policy. Thus, these RBAC models 

65 enable system administrators to describe the rights available 
to principals. The only decision a principal can make is 
whether to delegate all these rights to another principal. 
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Dynamic creation of permissions to delegate to processes is BRIEF DESCRIPTION OF THE DRAWINGS 

not possible because of the mandatory nature of the systems. ^ .„ 4 A , , . , . . , . 

r .nr>A^ * *u * *• . FIG. 1 illustrates how a dynamic derivation mechanism 

In addition, current RB AC systems that permit discretionary A A . . • . i 4 j 

; , AOI , : . , * li *u r pursuant to the present invention takes an authenticated 

access control use ACLs which do not enable the creation ol * . c r 4 . . 4 4 

, . ■ ■ i /. a^t * , ( j . i\ description of some executable content, a site security 

dynamic principals (because ACLs need to be updated), s r , . . _ , , ,. . . , \j 

rJ, c ) . , policy, and the identity of the downloading principal, and 

Inerero re, users, content execution systems, and application * • . , t ■• * r- ■ * r 

t i 1 j i i i i c a ui derives current and maximal permissions lor this instance ol 

developers must develop ad hoc mechanisms tor flexibly . A it . , , r 

j j • ii 1* *l • t.* *u * * u j i * a the content s download, 
and dynamically limiting the rights that are to be delegated 

to the content that they execute. There appears to be nothing FIG 2 illustrates five major steps implemented by the 

inherently limiting about RBAC that prevents its use in 10 dynamic derivation mechanism of the present invention, 

dynamic derivation of rights, but current systems are not FIG. 3 shows the site security policy which includes sets 

suitable for such derivation. of policy graphs used to derive the maximal permissions 

SUMMARY OF THE INVENTION contributions that any principal can delegate to the content 

and sets of permissions propositions used to compute the 

The present invention defines a dynamic derivation 15 current and maximal permissions from the maximal permis- 

mechanism that enables limited permissions to be dynami- s ions contributions and the current permissions contribu- 

cally and flexibly derived for executables based upon their tions delegated by those principals, 

authenticated description. The dynamic derivation media- FIG. 4 illustrates that the nodes of a policy graph's 

nism uses the authenticated description to determine the difected h CQnsisl of an |U|ributc a valuCj an entry> ^ 

maximal permissions that individual principals can delegate 2 o an access control list 

to the content. A principal's maximal permissions for con- ___ . .„ , , c , , . r if 

tent define a superset of the rights that that principal will . 5 1 lustrate j ■ J 3 ^*™? embodiment of the permis- 
actually delegate to that content. Aithough4e*intx»7 S10 f stru , cture : a ° d sho ™ tha ! P e ™ ons 1Qchlde P osltlve 

permissions are derived from predefi^pecttcatas, & and ne S atlve n S hts and transforms. 

specifications may be sensitive to.runtime state on the ^ FIG - 6 illustrates the structure of a derivation instance 

downloaded system or previous /tele'gaTic^s^o^nable^e which ma P s a content description and downloading principal 

d^iD^^^r^fiD^derrv^b^ Multipie"^rmcipafs"can t0 ite current and maximal permissions, given a site security 

delegate a subset of their maximal permissions for the policy. 

executable content. The mechanism uses policy for comb in- FIG. 7 illustrates how the first step of the dynamic 

ing the delegated permissions into the content's current 30 derivation mechanism creates a derivation instance and sets 

permissions. its attributes values. 

Therefore, trusted principals (e.g., system administrators) FIG. 8 illustrates how the second step of the dynamic 

can specify limits in which users, application developers, derivation mechanism retrieves the maximal and current 

and content execution systems can flexibly delegate rights to permissions propositions for the downloading principal and 

the specified content. 35 content description from the site security policy. 

In accordance with a preferred embodiment, a method is FIG. 9 illustrates how the third step of the dynamic 

denned for deriving current and maximal permissions for derivation mechanism derives the maximal permissions 

executable content using: from the contributions of each principal in the maximal 

a. one or more executable content descriptions; permissions proposition equation. 

b. one or more sets of permissions (access rights) that 40 FIG. 10 illustrates how the contributing principals are 
describe the operations that executable content can extracted from the maximal permissions proposition, 
perform on objects; FIG. 11 illustrates how results are derived from a policy 

c. one or more permission equations that compute one set graph. 

of permissions from one or more other sets of permis- ^- . n . . , , c iL , 

. r r 45 FIG, 12 illustrates how the fifth step of the dynamic 

' . . ... derivation mechanism derives the current permission set 

d. one or more permission propositions that specify con- from the rincipals that can co^te to the current per- 
ditions under which associated modifications to per- mission set 

missions apply; 

e. one or more policy graphs that associate permissions, 5Q DETAILED DESCRIPTION OF THE DRAWINGS 

permission equations, and/or permission propositions 50 M FIG. 1 depicts, the derivation mechanism (100) takes 

™ 1 f ra ?r nC l C ?'. , ■ • a D authenticated description of some executable content 

The method for ^enving current and maximal permissions (120) a ^ securi u (13Q) ^ ^ rf ^ 

comprise* U* tallowing steps; downloading principal (110) and derives current and maxi- 

f. denving one or more permission equations and one or S5 mal perrnissions (140,150) for this instance of the content's 
more permission propositions from policy graphs; download (160). When the content is executed by the 

g. deriving of one or more maximal sets of permissions downloading principal, its operations are to be authorized 
from policy graphs; against the current permissions (150). It is possible to extend 

h. selecting granted permissions from within an associ- the current permissions (150) by adding permissions that are 
ated maximal set of permissions; 60 within the maximal permissions of the content (140). 

i. combining one or more maximal sets of permissions FIG. 1 also shows that the derivation mechanism is 
into the maximal permissions using one permission executed by a Permission Derivation Server (170).<2Jiis$ 
equation and one or' more permission propositions; seiVeff(170)~^ 

j. combining one or more granted permissions into one system orspn-a-server-machme-tnisted by-the do^loading ^ 

current set of permissions which are a subset of the 65 princip aT ( e:g:,~a' secu re serv er in which- messages _ are , 

maximal permissions using one permission equation cOTnranieated.tb lHe.do^^lc^dmg.principa^s^ystem~via~a~ 

and one or more permission propositions. securerchannel). 
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As FIG. 2 depicts, the derivation mechanism (100) con- 
sists of the following five steps: (1) create a derivation 
instance (200) for this content description (120) and down- 
loading principal (110); (2) retrieve the current and maximal 
permissions propositions (210) from the site security policy 
(130) for the derivation instance (160); (3) derive the 
maximal permissions (150) from the contributions of each 
principal in the maximal permission proposition (220); (4) 
obtain the current permissions contributions (230) delegated 
by each principal in the current permission proposition 
(300), as illustrated in FIG. 3; and (5) compute the current 
and maximal permissions (140,150,240) using the current 
and maximal permissions propositions (300,310) and the 
current and maximal contributions (230,220) of the propo- 
sitions' principals. The current permissions (150), by 
definition, must always be a subset of the maximal permis- 
sions (140). 

The description of executable content (120) is a set of 
attribute-value pairs. One possible embodiment is RDF 
("Resource Description Framework") labels that describe 
the meta-data of a website 3 s URI ("Universal Resource 
Identifier"). RDF is a Web Consortium Activity (see 
http://www.w3.org/metadata/RDF/overview.html). 
Attributes with string values can be used to describe a URI. 

Table 1 shows attributes used in a preferred embodiment 
for the content description (120). This is a modification of 
the content description structure used by FlexxGuard (see N. 
Islam et al., A Flexible Security System for Using Internet 
Content, in IEEE Software, pgs. 52-59, September, 1997). 

TABLE 1 



Content Description Attributes 



120 Description Field Definition 



121 Manufacturer 


Content's originating 




manufacturer 


122 Description Author 


Principal responsible 




for the description 


123 Application Classes 


Application types 




to which the 




content belongs 


124 Application Name 


Application name 


125 Version 


Content version 


126 Requested Permissions 


Permissions 




requested by the content 


127 Content Digest 


A cryptographic 




digest of the content 


128 Application Role 


Role of content in 


the application 



The content is created by its manufacturer (121). The 
content description (120) is authenticated to be from the 
description author (122). The description author (122) can 
be different from the manufacturer (121), but the derivation 
mechanism (100) may limit the permissions granted (140, 
150) based on the site security policy's (130) trust in the 
description author (122). The application classes (123) indi- 
cate the types of applications to which this content belongs. 
The application name (124) and version (125) specify the 
name and version of the content. The content's crypto- 
graphic digest (127) enables verification that the content 
description (120) refers to the expected content. In a pre- 
ferred embodiment, a one-way, collision-free hash function 
(see National Institute of Standards and Technology, U.S. 
Department of Commerce, Secure Hash Standard, Publica- 
tion FIPS PUB 180-1) is used to generate such digests. The 
application role (128) specifies the principal that the content 
assumes from the application's perspective. 

Content descriptions (120) should be cryptographically 
authenticated (i.e., integrity and source verification) or sent 
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over a trusted communication link prior to use. In a preferred 
embodiment, public key cryptography is used to verify the 
integrity and source of content descriptions (120). Two 
additional fields are added to the description (120): (1) a 

5 field that contains a list of signatures and (2) a field that 
contains a list of public key certificates. The certificates 
enable the verification of any of the contained signatures. 

FIG. 3 shows the site security policy (130). It includes sets 
of policy graphs (320) used to derive the maximal permis- 

io sions contributions (150) that any principal can delegate to 
the content and sets of permissions propositions (300,310) 
used to compute the current and maximal permissions 
(140,150) from the maximal permissions contributions (150) 
and the current permissions contributions delegated by those 

15 principals. 

FIG. 3 also shows the structure of a policy graph (320). A 
policy graph consists of a directed graph (324), a traversal 
method (322), a combination method (323), an access con- 
trol list (325), and a downloading principal to whom the 

20 graph applies (321). The directed graph (324) stores the 
security policy specific to the specified downloading prin- 
cipal (321). The traversal method (322) determines how the 
directed graph (324) is traversed (e.g., from a root down or 
from a leaf up) when it is evaluated. The combination 

25 method (323) determines how the node's entries (430) are 
combined into the resultant policy value. The access control 
list (325) limits access to the policy graph (320). Principals 
can be permitted to modify any of the policy graph attributes 
(321-325). 

30 As shown in FIG. 4, the nodes (400) of a policy graph's 
(320) directed graph (324) consist of an attribute (410), a 
value (420), an entry (430), and an access control list (440). 
The traversal method uses the node attribute (410) and node 
value (420) to match the node with the content's description 

35 (120). If a match occurs, then the combination method (323) 
applies the node entry (430) to the current result derived so 
far from the policy graph traversal (810), In a preferred 
embodiment, node entries (430) refer to permissions. The 
access control list (440) controls access to the node. In a 

40 preferred embodiment, principals can be permitted to read, 
write, delete, and create children of the node. 

In the directed graph (324) shown in FIG. 4, an example 
traversal method (322) specifies that traversal starts at the 
root of the directed graph (324) and repeatedly follows the 

45 child link whose node's (400) attribute (410) value (420) is 
the same as the content description's (120) value for that 
attribute. An example combination method (323) is the 
union set operator. A traversal method (322) that goes from 
the root (400) to the manufacturer=IBM node (401) to the 

50 description author-IBM (402) to the application classes^ 
games node (403) results in the permissions (580) P^ U P 0 
UP C . 

Note that Netscape content shares the same node at the 
application type level of the policy graph as the IBM content 

55 in our example. Therefore, the resulting permissions (580) 
for a content description (120) of manufacturer=Netscape 
(121), description author=Netscape (122), and application 
classes=games (123) is P* U P^ P c . 

The permissions structure (330) in a preferred embodi- 

60 ment is shown in FIG. 5. Permissions (330) include positive 
(550) and negative rights (560) and transforms (570). Rights 
associate an object group (551) with a set of operations that 
are permitted or denied (552) and a limit for the number of 
times this permission may be used (553). In authorization, if 

65 a positive right (550) exists that grants an operation on an 
object and a negative right (560) exists that precludes the 
operation on that object, then the operation is not authorized. 
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That is, positive rights (550) are always superseded by added to the maximal permissions set (900) for the deriva- 
negative rights (560). Object groups (551,561) may refer to tion instance (160) (950). This is repeated for each maximal 
logical objects and be mapped to physical objects at runtime contributing principal (1001) (960). Once all the contribu- 
to permit the same specification to cover multiple principals. tions have been collected, the maximal permissions (150) 
Transforms (570) associate a delegating principal's (571) 5 are computed using the maximal permissions set (900) and 
action (e.g., operation) (572) with modifications to permis- the maximal permissions propositions (310). 
sions (573) (e.g., addition or removal of rights). For a As shown in FIG. 10, the contributing principals (1000) 
transform (570) to apply, the rights to be delegated must be are extracted from the maximal permissions proposition 
within the delegating principal's (571) maximal permissions (310) (910). First, the equation (312) is extracted from the 
contribution (140) for the delegatee's content. Also, the 10 maxima] permissions proposition (310) (1010). For each 
delegated rights must be within the maximal permissions term in the equation, the principal specified is collected into 
( 140) of th e delegatee's content. TEapsfojTO Si(>51^ the contributing principals (1000) (1020-1040). This is done 
mereurrenflge; pm until all the terms in the equation (312) have been examined 
the^agplic.ation. (1050). 
^^^re^ermissions propositions (300,310) describe how the 15 Results (1100) are derived from policy graph (320) (810) 
current and maximal permissions (140,150) are derived as shown in FIG. 11. First, the results are set to null (1110). 
from the contributions from multiple contributing principals. Then, the traversal method (322) specifies the next node to 
In a preferred embodiment, set operations (e.g., union, visit (1120). If the node is not null (1130), then the node's 
intersection) (301,311) are used to combine the permissions access control list is checked to determine whether the read 
contributed by the contributing principals (110) and con- 20 is permitted (1140). If the read is not permitted, the deriva- 
straint propositions (302,312) imply the addition or removal tion is aborted (1150). Otherwise, the combination method is 
(e.g, implication of positive or negative rights) of permis- called to update the result (1100) (1160). This is repeated 
sions. until there are no more nodes to visit (1130). The traversal 
A derivation instance (160) maintains the state of the method (322) and combination method (323) are policy- 
derivation. Its structure is shown in FIG. 6. A derivation 25 specific. 

instance (160) maps a content description (120) and down- As shown in FIG. 12, step 4 derives the current permis- 
loading principal (110) to its current and maximal permis- sion set (1200) from the principals that can contribute to it. 
sions (140,150) given a site security policy (130). Other First, the current contributing principals are derived from the 
fields can be added to maintain the state of the derivation. current permissions proposition (310) (1200). The current 
Mechanism Description 30 permission set is set to null (1210). For each current con- 
As shown in FIG. 7, step 1 of the derivation mechanism tributing principal (1002), its delegation mechanism (1220) 
(100) creates a derivation instance (160) (700) and sets its is executed. A delegation mechanism (1220) implements the 
attribute's values (710-740). The downloading principal principal-specific mechanism for obtaining its contribution 
(110), content description (120), and site security policy to the current permission set (1290) from the principal. If 
(130) are assigned to their corresponding attributes 35 return is true, skip to the next current contributing principal 
(710-730) in the derivation instance (160). The remaining (1230-1240). Otherwise, check if permissions returned are 
attributes are set to null (740). a subset of the principal's maximal permission set entry and 
As shown in FIG. 8, step 2 of the dynamic derivation maximal permissions computed instep 3 (150) (1250). If so, 
mechanism (100) retrieves the maximal and current permis- add the entry to the current permission set (1290) (1270). A 
sions propositions (210) for the downloading principal (110) 40 mapping of the principal to its contribution is collected into 
and content description (120) from the site security policy the current permission set (1290). If not, notify the delega- 
(130). First, the maximal permissions proposition policy tion mechanism of an error and repeat (1260, 1220). When 
graph is retrieved for this downloading principal (800). no more principals want to contribute, the current permis- 
Next, at (810) the maximal permission propositions (310) sion set is complete (1280), 

are derived given the policy graph (320) and the content 45 Step 5 combines the elements of the current permission 

description (120) (as the description (1170) as described set (1290) using the current permission propositions (300) to 

below and shown in FIG. 11). The current permission create the current permissions (140) for the derivation 

propositions (300) are retrieved similarly. First, its policy instance (160). Since each contribution in the current per- 

graph (320) is retrieved using the downloading principal mission set (1290) is a subset of the maximal permissions 

(820). Next, at (830) the current permission propositions 50 (150) and no equation (302) operations are used that gen- 

(300) are derived from the policy graph (320). erate new set elements, the current permissions derived must 

As shown in FIG. 9, step 3 derives the maximal permis- be a subset of the maximal permissions (150). 
sions (150) from the contributions of each principal in the 

maximal permissions proposition equation (312). First, the LXAMPLhS 

maximal contributing principals for the maximal permis- 55 This section describes how the dynamic derivation 

sions (150) are retrieved from the maximal permissions mechanism can improve the security of the derivation 

proposition equation (312) (910). Next, the number of mechanism of an existing system (FlexxGuard) and how it 

principals are counted, and the maximal permission set is set can be used to enable collaborative applications to control 

to null (920). Then, for each maximal contributing principal, derivation (collaborative system server). 

a maximal permissions policy graph is retrieved from the 60 #IE)^l»lt Elex«x©uaTai 

site security policy (130) (930). The maximal permissions JDK 1.1 FlexxGuard is an extension of the JDK 1.1 

policy graph is traversed (as described below and shown in Appletviewer that enables users to assign more liberal 

FIG. 11) using the content description (120) and the down- permissions (480) to authenticated content from trusted 

loading principal (110) (as the description (1170)) to obtain sources while still tightly restricting untrusted content (see 

a maximal permissions contribution (1100) for this maximal 65 N. Islam et al., A Flexible Security System for Using Internet 

contributing principal (1001) and derivation instance (160) Content, in IEEE Software, pgs. 52-59, September, 1997). 

(810). A mapping of the principal to this entry (1100) is In FlexxGuard, downloading principals (110) and/or system 
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administrators specify maximal permissions (150) for con- 
tent based on their descriptions (120). The content descrip- 
tion (120) for FlexxGuard content is shown in Table 2. 
Downloaded content can include a request for permissions 
(126) from the downloading principal (110). If this request 5 
(126) is a subset of the maximal permissions contribution of 
the system administrator, then the current permissions (140) 
of the content are set to the requested permissions (126). If 
not, then the downloading principal (110) can selectively 
override and/or modify the rights in the system administra- 1Q 
tor's maximal permissions contribution to create the current 
permissions (140) for the content. 

(121) Manufacturer 

(124) Application Name 

(126) Requested Permissions 15 

(127) Content Digest 

Table 2. FlexxGuard Content Description 

Using the dynamic derivation mechanism (100) to imple- 
ment the same security requirements as FlexxGuard, the 
content execution system defines the maximal permissions 20 
contributions for users and system administrators to be the 
users 5 full permissions. System administrators express their 
current permission contributions for content based on the 
content's authenticated description (120). ^r ^^u^r ^eag 
<py 4 eiride|ithe^ ^delejp:tioT»^entireLy. 25 

Therefore, the current permission proposition equation (302) 
defines that the user's current permission contribution over- 
rides the system administrators. If the requested permissions 
(126) are a subset of the system administrator's current 
permissions contribution, then the user grants these as the 30 
current permissions (140) of the content. The current per- 
missions (140) are unchanged throughout the content's 
execution. 

Security can be enhanced using the dynamic derivation 
mechanism (100) because the user and system administrator 35 
can be restricted to maximal permissions contributions that 
limit the rights that each may grant to content. Therefore, a 
user can be prevented from arbitrarily overriding the system 
administrator's contribution. The maximal permission con- 
tributions can be derived as described above (see FIG. 9) 40 
given the authenticated content description (126). The cur- 
rent permissions equation for this case would union the 
permissions added by the user to the set difference of the 
permissions granted by the system administrator and the 
permissions removed by the user. 45 
Collaborative System Server 

In a collaborative system server, collaborative applica- 
tions (i.e., applications that manage collaborations) and 
collaborative actions of the participants are implemented as 
downloaded content. Application content is used directly by 50 
downloading principals (e.g., through an interface) to imple- 
ment their actions in the collaboration and manage their 
view of the state of the collaboration. Collaborator content 
implements other users' actions in the application. For 
example, a collaborative editor is an application, and col- 55 
laborators use content to implement their editing operations 
on documents. 

In a collaborative system, the system administrator and 
user (i.e., downloading principal) determine the rights to 
grant (current and maximal) to the collaborative application. 60 
However, the collaborative application may, in addition to 
the user and system administrator, grant rights to the appli- 
cation's collaborative content. This enables objects that are 
controlled by the collaborative application to be made 
available based on application-specific policy. For example, 65 
a collaborative editor may decide to give all collaborators 
write access to a file object once the user has loaded it into 
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the editor. However, some participants may only be permit- 
ted read access to the object (e.g., based on their role in the 
collaboration). This policy enables collaborative applica- 
tions to selectively grant rights that are granted to it by the 
user. 

This policy is implemented by system administrators 
defining policy graphs that determine the maximal permis- 
sions contributions of themselves, users, and the collabora- 
tive application. The permissions equations (302,312) then 
union the maximal and current permissions contributions 
derived and selected, respectively. In addition, the use of 
object groups in permissions (480) enables users to select 
the objects to which the collaborative application may have 
administrative control. 

Consider the collaborative editor example again. Suppose 
the users' maximal permissions contribution permits them to 
grant read and write access to a set of "editable" files to the 
collaborative editor. The users may grant the collaborative 
application maximal permissions (150) to read and write 
these files. However, the user only grants the collaborative 
application access to a set of "active editable" files (i.e., its 
current permissions (140) only include read/write access to 
these files). The members of this set are determined dynami- 
cally by the user (e.g., using a trusted interface to select files 
to add to the set). Therefore, the collaborative application 
may be limited in the rights it can manage. Also, the limited 
set of rights may be determined dynamically. 

The collaborative application can grant these rights to 
participants in the collaboration in a controlled, application- 
specific manner. In this case, the user and system adminis- 
trator make no contribution to the maximal permissions of a 
participant. The collaborative application maximal permis- 
sions contribution makes the "editable" files available to the 
participants. The rights to access the files can be limited 
based on whether the participant is active (read/write) or 
passive (read only). The participant's current permissions 
are the "active editable" set of files that the user determines 
(however, this could be limited through the use of an 
indirection, such as "participant's active editable files"). 
Thus, participants can obtain their rights to files based on the 
user's decision about what files are needed and the appli- 
cation's policy that maps participants to roles. 

Step 5 combines the elements of the current permission 
set (1290) using the current permission propositions (300) to 
create the current permissions (140) for the derivation 
instance (160). Since each contribution in the current per- 
mission set (1290) is a subset of the maximal permissions 
(150) and no equation (302) operations are used that gen- 
erate new set elements, the current permissions derived must 
be a subset of the maximal permissions (150). 

Having thus described our invention, what we claim as 
new, and desire to secure by Letters Patent is: 

1. A method for deriving current and maximal permis- 
sions for executable content using: 

a. one or more executable content descriptions; 

b. one or more sets of permissions (access rights) that 
describe the operations that executable content can 
perform on objects; 

c. one or more permission equations that compute a set of 
permissions from one or more other sets of permis- 
sions; 

d. one or more permission propositions that specify con- 
ditions under which associated modifications to per- 
missions apply; 

e. one or more policy graphs that associate permissions, 
permission equations, and/or permission propositions 
with graph nodes; 
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wherein the method for deriving current and maximal per- 
missions comprises the following steps; 

f. deriving one or more permission equations and one or 
more permission propositions from policy graphs; 

g. deriving one or more maximal sets of permissions from 
policy graphs; 

h. selecting granted permissions from within an associ- 
ated maximal set of permissions; 

i. combining one or more maximal sets of permissions 
into the maximal permissions using one permission 
equation and one or more permission propositions; 

j. combining one or more granted permissions into one 
current set of permissions which are a subset of the 
maximal permissions using one permission equation 
and one or more permission propositions. 

2. A method as claimed in claim 1, wherein the content 
descriptions comprise attribute -value pairs. 

3. A method as claimed in claim 2, wherein the attributes 
in the content description include the content manufacturer, 
content description author, content application class, content 
name, and content version. 

4. A method as claimed in claim 2, wherein policy graph 
derivation retrieves the entry that corresponds to the 
attribute -value pairs in the content description. 

5. A method as claimed in claim 1, wherein permissions 
specify operations that can be performed. 

6. A method as claimed in claim 5, wherein permissions 
grant an operation, such that an authorization mechanism 
permits its execution. 

7. A method as claimed in claim 6, wherein transforms are 
specified which define events that modify current permis- 
sions. 

8. A method as claimed in claim 5, wherein permissions 
are either positive, such that they grant an operation, or 
negative, such that they preclude an operation. 

9. A method as claimed in claim 1, wherein permissions 
specify operations that can be performed on objects. 

10. A method as claimed in claim 9, wherein the objects 
in permissions refer to one or more objects. 

11. A method as claimed in claim 10, wherein the objects 
are mapped to physical object names at runtime. 

12. A method as claimed in claim 1, wherein permissions 
specify the operations that can be performed on objects and 
a limit to the number of such operations. 

13. A method as claimed in claim 1, wherein permission 
equations perform set operations on one or more sets of 
permissions to compute a single set of permissions. 

14. A method as claimed in claim 13, wherein permission 
equations use permissions which are associated with specific 
principals. 

15. A method as claimed in claim 14, wherein specific 
principals include a system administrator, a downloading 
principal, and an application for which the content is being 
used. 

16. A method as claimed in claim 1, wherein permission 
propositions add, remove or restrict a permission. 

17. A method as claimed in claim 16, wherein permission 
propositions specify that the presence of two or more 
specific permissions results in the removal of one of the 
permissions. 

18. A method as claimed in claim 16, wherein permission 
propositions specify that the presence of two or more 
specific permissions results in the restriction of one of the 
permissions. 

19. A method as claimed in claim 16, wherein permission 
propositions specify that the presence of one or more 
specific permissions results in the addition of one or more 
permissions. 

20. A method as claimed in claim 1, wherein a policy 
graph contains one or more linked nodes, and each node is 
linked to at least one other node in the policy graph. 
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21. A method as claimed in claim 20, wherein nodes are 
associated with specific attributes. 

22. A method as claimed in claim 20, wherein the 
attributes are totally ordered. 

5 23. A method as claimed in claim 20, wherein the nodes 
associate attribute-value pairs with entries. 

24. A method as claimed in claim 20, wherein a node is 
linked to a node of the next lesser attribute in the total order 
if the entry of the second node is consistent with an 

10 extension of the description by that attribute-value pair. 

25. A method as claimed in claim 20, wherein access to 
nodes is authorized based on a node access control list. 

26. A method as claimed in claim 20, wherein the policy 
graph is associated with one or more principals. 

15 27. A method as claimed in claim 20, wherein selection of 
a next node to access in a policy graph traversal is deter- 
mined by a traversal method. 

28. A method as claimed in claim 20, wherein derivation 
of the results of a policy graph traversal is specified by a 

20 combination method which combines a current node's entry 
with a result derived so far. 

29. A method as claimed in claim 28, wherein the com- 
bination method combines values of a current node's entry 
before traversing its children/parents. 

25 30. A method as claimed in claim 28, wherein the com- 
bination method combines values of a current node's entry 
after traversing its children/parents. 

31. A method as claimed in claim 20, wherein access to 
the policy graph is authorized using an access control list. 

30 32. A method as claimed in claim 20, wherein the policy 
graph nodes store permission equations as entries. 

33. A method as claimed in claim 20, wherein the policy 
graph nodes store permission propositions as entries. 

34. A method as claimed in claim 20, wherein the policy 
35 graph nodes store permissions as entries. 

35. A method as claimed in claim 20, wherein a node is 
selected if its value for an attribute is the same as that of the 
description. 

36. A method as claimed in claim 20, wherein a node is 
40 selected if its value for an attribute includes the value of that 

attribute in the description. 

37. A method as claimed in claim 20, wherein the policy 
graph derivation unions the entries that correspond to the 
nodes selected in graph traversal by the traversal method. 

45 38. A method as claimed in claim 20, wherein the policy 
graph derivation intersects the entries that correspond to the 
nodes selected in the graph traversal by the traversal method. 

39. A method as claimed in claim 1, wherein site security 
policy concerning permissions, permission equations, per- 

50 mission propositions, and policy graphs is stored on one or 
more machines. 

40. A method as claimed in claim 39, wherein site security 
policy is stored on a downloading principal's machine. 

41. A method as claimed in claim 39, wherein site security 
55 policy is stored on a machine that is a secure server. 

42. A method as claimed in claim 1, wherein a principal 
which intends to run the executable is used to derive 
permission equations, permission propositions, and/or maxi- 
mal sets of permissions. 

43. A method as claimed in claim 1, wherein a principal 
60 delegates any rights to content within its maximal permis- 
sions for that content. 

44. A method as claimed in claim 1, wherein a principal 
delegates a right to content if it is within its maximal 
permissions for that content and the right is within the 

65 content's maximal permissions. 

* * * * * 
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